home *** CD-ROM | disk | FTP | other *** search
/ Graphics Plus / Graphics Plus.iso / amiga / viewers / gl1_3.lzh / gl.man < prev    next >
Encoding:
Text File  |  1991-06-20  |  9.7 KB  |  241 lines
  1.                              GL Documentation 
  2.  
  3. Software:
  4.     GL
  5.     GLSplit
  6.     Pictor
  7.  
  8. Purpose:
  9.     To fiddle with GRASP animation files. These are found on PClones,
  10.     with the extension ".GL".
  11.  
  12.     GRASP is a product of Microtex Industries, Inc.
  13.  
  14. Author:
  15.     John Bickers (JJB Templar)  - jbickers@templar.actrix.gen.nz
  16.  
  17. Credits:
  18.     This was written using SAS C 5.10a.
  19.  
  20.     The digital dissolve effect (fade 20) is from "A Digital 'Dissolve'
  21.     Effect", by Mike Morton, pg 221 of "Graphics Gems".
  22.  
  23.     The format of a .GL file was obtained from the documentation file
  24.     for xgrasp, a Sun .GL player written by Patrick J. Naughton
  25.     (naughton@sun.com). This file included what appears to be documentation
  26.     from an early (Useware) version of GRASP.
  27.  
  28.     The formula to convert from an RGB triple to a grayscale level is
  29.     from Usenet's comp.graphics FAQ.
  30.  
  31.     Motivation is from MANDY-2.GL, which I saw running on a PS/2, and
  32.     which convinced me that perhaps PClone animations are worth
  33.     noticing.
  34.  
  35. Using GL:
  36.     This program is the .GL player. It has a number of limitations, which
  37.     include no font or text support, only two fades (0 and 20), etc.
  38.  
  39.     The CLI usage is:
  40.  
  41.         WSH 3> gl [-g] [-p] filename
  42.  
  43.     The optional "-g" parameter tells GL to use a grayscale colormap for
  44.     the data. This is usually necessary for VGA animations, which have
  45.     256-color palettes. The original 256 colors are then mapped onto
  46.     16 gray levels. Note that this makes a number of GRASP color commands
  47.     and tricks useless, since the source data is converted into 4 bits
  48.     per pixel during the "cload" or "pload" commands, and cannot be
  49.     remapped to a new palette.
  50.  
  51.     The optional [-p] parameter tells GL to use the picture offset
  52.     positions given in the .PIC files as their initial offset positions.
  53.  
  54.     GL can only handle two of the many video modes a .GL may have. These
  55.     are CGA 640x200/1 ('C'), and VGA 320x200/8 ('L'). These happen to
  56.     be the only sample files available to me. I'd be happy to add more,
  57.     should the opportunity arise.
  58.  
  59.     While GL is running, it is possible to send input to it. There
  60.     are two "input windows of opportunity". The 1st is at the end of
  61.     each command, when GL does a quick check of it's task signals. The
  62.     2nd is during the .GL "waitkey" command.
  63.  
  64.     Window 1: no delay.
  65.         ^C in the CLI you started GL from will kill it.
  66.         Esc will quit.
  67.         Space will go into pause mode.
  68.  
  69.     Window 2: will delay until "waitkey" timeout occurs.
  70.         Esc will quit.
  71.         Space will go into pause mode.
  72.  
  73.     Once in pause mode, a few key commands are available:
  74.         Space will leave pause mode, but reenters it at next window 2.
  75.         The 'S' key will save the current screen as an IFF ILBM.
  76.         The 'I' key will output some status info to the console.
  77.         Any other key leaves pause mode.
  78.  
  79.     GL was written on an A2630. I've optimized some parts of the drawing
  80.     for VGA 'L' animations in assembler, but GL is still a little slow on
  81.     a 68000.
  82.  
  83.     In my opinion, converting a .GL to something nice for the Amiga is
  84.     too much hassle to write a free program for (I don't know any
  85.     convenient Amiga formats, for example. ANIM option 5 is out). The
  86.     easiest approach is probably to extract the elements of the
  87.     animation, convert them to HAM if necessary, then put them back
  88.     together using an Amiga animation program.
  89.  
  90.     People on Usenet have recommended Director 2.0(*) for this purpose,
  91.     though as far as I know no-one has tried it. Let me know if you
  92.     do (or if you can get format specs, and want me to take a shot at
  93.     writing an automatic converter).
  94.  
  95.     (*) Note I have no affiliation with this program. I've never even
  96.     _seen_ it.
  97.  
  98. Using GLSplit:
  99.     This is like GRASP's "GLIB" program, but with extraction and listing
  100.     capabilities only. A .GL file is similar to an archive, and GLSplit
  101.     will allow one to extract any file one wishes.
  102.  
  103.     The CLI usage is:
  104.  
  105.         WSH 3> glsplit [-l] [-oprefix] [-xname] filename
  106.  
  107.     If no options are specified, glsplit will extract all files from
  108.     "filename" into the current directory.
  109.  
  110.     The optional "-l" parameter will produce a list of the files
  111.     within the .GL.
  112.  
  113.     The optional "-o" parameter specifies a prefix for the output files.
  114.     For example, if one wanted to extract all files to ram:, one would
  115.     use:
  116.         WSH 3> glsplit -oram: filename
  117.  
  118.     The optional "-x" parameter specifies that a particular file should
  119.     be extracted. For example, if one of the files in the .GL file happened
  120.     to be "main.txt", you could extract just that file with:
  121.         WSH 3> glsplit -xmain.txt filename
  122.  
  123. Using Pictor:
  124.     This program is intended to either display or convert PCPaint
  125.     picture files. These include the .PIC and .CLP files found in .GLs.
  126.     The same video modes are recognised as with GL - that is, Pictor
  127.     only knows how to handle CGA ('C') and VGA ('L') pictures. Again
  128.     similar to GL, Pictor displays 'L' mode pictures into a 4-bitplane
  129.     LORES screen.
  130.  
  131.     The CLI usage is:
  132.  
  133.         WSH 3> pictor [-vo] [-g] [-sname] [-lname] [-wname] filename
  134.  
  135.     The optional "-v" parameter generates information from the header
  136.     of the picture. If an 'o' follows the 'v', then this is all the
  137.     processing that occurs (ie: [v]erbose [o]nly).
  138.  
  139.     The optional "-g" parameter uses a grayscale colormap. HAM etc
  140.     conversion is better done with other tools, like HamLab(*).
  141.  
  142.     The optional "-s" parameter tells Pictor to save the colormap of
  143.     the picture as a seperate file. The default name is "ram:savecolor",
  144.     and can be overridden by placing a filename directly after the "-s".
  145.     The purpose of this parameter is to provide .CLP (clip) pictures with
  146.     a colormap, since they do not usually have one. For example, if you
  147.     had two files "palette.pic" and "clip1.clp", you could display the
  148.     .clp file with:
  149.         WSH 3> pictor -s palette.pic
  150.         WSH 3> pictor -l -g clip1.clp       ;or pictor -l -w clip1.clp
  151.  
  152.     The optional "-l" parameter tells Pictor to load the colormap
  153.     for the picture from a file. The default name is the same as for
  154.     the "-s" parameter. This colormap can be used along with the
  155.     "-g" and "-w" options, either to display correct grayscales, or
  156.     to write out the correct colormap to the FIG workfile.
  157.  
  158.     The optional "-w" parameter tells Pictor to write out the picture
  159.     as a workfile for my FIG(**) programs. The default name is
  160.     "ram:pictor.wrk". Older versions of the FIG software will not work
  161.     with these files, since I've added a two-byte identifier to the
  162.     workfile header in order to identify them to HamLab. I either use
  163.     FIG, or a filter that reads a workfile into HamLab, to process these
  164.     files.
  165.  
  166.     (*) HamLab is an image conversion package written by Ed Hanway. The
  167.     package is shareware, though freely redistributable versions are
  168.     available. As of this writing, the version number is 1.1, and
  169.     Ed's email address is "jeh@sisd.kodak.com".
  170.  
  171.     (**) FIG is an image conversion package written by me, before I
  172.     got HamLab. I still find it useful, since it only fiddles with 8-bit
  173.     data (therefore requires less space) and is script-driven.
  174.  
  175. Known problems:
  176.  
  177.     Symptom: the right edge of a "clip" disappears from time to time.
  178.         This is a fault in the shifting routine not correctly handling
  179.         clips that overlap the left edge of the screen.
  180.  
  181.     Symptom: parts of the picture are being drawn as black.
  182.         Some animations load "clip" data before they load "pic" data.
  183.         "clip" data does not usually contain color information, so when
  184.         the image data is converted to bitplane format, the result is
  185.         a blank clip, since the colors in the palette have not yet
  186.         been initialized.
  187.  
  188. To do:
  189.     Implement GRASP commands/video modes as required, I guess. No big
  190.     deal. As I get new animations, I'll implement basic stuff required
  191.     to play them.
  192.  
  193.     More assembler.
  194.  
  195.     Consistent operation across video modes and similar operations.
  196.  
  197.     Dithering in the grayscale mode?
  198.  
  199.     Change in the way things are done, to use the Blitter, double
  200.     buffer, etc?
  201.  
  202. Personal stuff:
  203.     Suggestions are welcome, and may even be implemented. I can be
  204.     contacted at the following:
  205.  
  206.     Snail:  John Bickers,
  207.             214 Rata St,
  208.             Naenae 6301,
  209.             New Zealand.
  210.  
  211.     Email:  jbickers@templar.actrix.gen.nz
  212.  
  213.     Phone:  677-334, 672-085, or 746-625.
  214.  
  215.     People who use this program are also invited to send some notification
  216.     of their existence to any of the above points. Feel free to pay
  217.     something (esp. if you want to request that something be added :) too,
  218.     but payment is not a requirement. I'd be more interested in
  219.     animations, actually (NOT NOT NOT via email! I have to pay $$ for
  220.     that!). Either Amiga disks, or MS-DOS disks up to 1.4M, are ok. The
  221.     nature of the animations is not a problem either. X-rated or clean
  222.     are both fine.
  223.  
  224.     This program may be redistributed freely, but not for commercial gain
  225.     (ie: Fred Fish type costs are ok). Note that you should include the
  226.     documentation.
  227.  
  228.     GL, GLSplit and Pictor are Copyright ⌐ 1991 by John Bickers.
  229.  
  230. History:
  231.     GL1.0   Began on 23rd Mar '91. Didn't do clips right.
  232.     GL1.1   Released. 68000 performance is slow and looks wavy.
  233.     GL1.2   Has some assembler optimization. 68000 copying performance is
  234.             ok. Still slower than it should be, but the waves appear to
  235.             be significantly reduced.
  236.     GL1.3   Added a variety of commands, transparency, offset positioning,
  237.             etc. Mostly motivated by animations received from David Yee.
  238.  
  239. Disclaimer:
  240.     "It works on my machine" (so far :).
  241.